Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/internet-drafts/draft-ietf-iplpdn-multi-isdn-00.txt

Text File | 1993-03-03 | 17.4 KB | 558 lines

Draft                Multiprotocol ISDN            Feb. 1993


INTERNET DRAFT
Expires: August 16, 1993




      The Transmission of Multi-protocol Datagrams
                    over Circuit-mode ISDN


Keith Sklower
Computer Science Department
University of California, Berkeley

1.  Status of This Memo

This  document  is  an  Internet Draft.  Internet Drafts are
working documents of the  Internet  Engineering  Task  Force
(IETF),  its Areas, and its Working Groups.  Note that other
groups may also distribute  working  documents  as  Internet
Drafts.

Internet  Drafts  are draft documents valid for a maximum of
six months.  Internet Drafts may be  updated,  replaced,  or
obsoleted  by other documents at any time.  It is not appro-
priate to use Internet Drafts as reference  material  or  to
cite  them  other  than  as a ``working draft'' or ``work in
progress.''

Please check the 1id-abstracts.txt listing contained in  the
internet-drafts    Shadow    Directories   on   nic.ddn.mil,
nnsc.nsf.net,    nic.nordu.net,     ftp.nisc.sri.com,     or
munnari.oz.au  to  learn  the current status of any Internet
Draft.

2.  Abstract

This document describes means for transmitting Internet Pro-
tocols  across public data networks using circuit-mode ISDN.
It describes compatible alternatives, discusses the relative
merits  of  each  and  provides  methods  for discrimination
between them.  The intention is to  capture  in  a  slightly
more  formal  way the level of consensus reached at the 24th
and 25th IETF meetings.

3.  Acknowledgements

The author specifically wishes to thank Clifford  Frost  and
William  Jolitz  for  many extensive discussions on the sub-
ject, and more generally  the  IP  over  Large  Public  Data


Sklower                                     [Page 1]



Draft                Multiprotocol ISDN            Feb. 1993


Networks  working  group,  whose  deliberations this memo is
supposed to reflect.  Extensive references are made to  ear-
lier work by Leifer et al. [1], and Murakami et al. [2].

4.  Conventions

The  following language conventions are used in the items of
specification in this document:

o    Must, Shall or Mandatory -- the  item  is  an  absolute
     requirement of the specification.

o    Should  or  Recommended -- the item should generally be
     followed for all but exceptional circumstances.

o    May or Optional -- the item is truly optional  and  may
     be  followed  or  ignored according to the needs of the
     implementor.

5.  Introduction

The advent of Circuit-mode ISDN has provided the possibility
of much higher rates of information exchange than previously
possible over modems and voice-grade lines.   We  anticipate
the  use  of this technology to encourage ``tele-commuting''
(making it more possible for people to work  effectively  at
home),  and  to  reduce  the  cost of data communications in
businesses having  geographically  dispersed  sites.   Other
applications,  such  as  multi-media  conferencing, are much
more economically feasible than before.  The contribution by
Murakami  also  cites  the use of ISDN to acquire additional
bandwidth for  handling  excess  traffic  in  parallel  with
leased  lines, and more generally back-up of a failed leased
line.

Given the newness of the technology, the  diversity  of  its
applications,  and its wide availability, it is not surpris-
ing that a number of incompatible link level  protocols  are
coming  into  use  for  the  transmission  of data over ISDN
links.  Examples are the use of SLIP [3] and PPP [4,5]  over
asynchronous  terminal  adapters  using  V.120 [6], PPP over
synchronous terminal adapters using V.120 or  directly  over
the  B channel via native ISDN interfaces, and both the Mul-
tiprotocol Encapsulation  over  X.25  [7],  or  Mutltiprocol
Encapsulation  over  Frame Relay [8] directly on the B chan-
nel.  There are even  other  examples  cited  in  Murakami's
paper.

In this paper we recommend a primary choice of encapsulation
- -- that described in RFC 1294.  We also suggest two  accept-
able alternatives for specific situations: PPP and X.25.




Sklower                                     [Page 2]



Draft                Multiprotocol ISDN            Feb. 1993


The contribution by Murakami suggests using out-of-band sig-
naling for negotiating the  link-layer  protocol  and  other
configuration  parameters  using  ISDN  Information Elements
such as UUI and BC.  It is the experience of the members  of
the  IPLPDN  that ISDN implementation are as yet so diverse,
the deployment of Switching System 7 so  limited,  and  sub-
scription  policies  by the regional providers so different,
that user cannot depend on having these information elements
passed  end-to-end.  The likeliest element to be passed end-
to-end is LLC; this memo proposes a method for  chosing  the
link-layer  protocol  based  on this element when available.
Where it is not available,  an  algorithm  is  proposed  for
``negotiating'' the protocol by in-band exchange of data.

Other  configuration  parameters  can  be negotiated in band
using PPP, even for the  Frame  Relay  and  X.25  cases,  as
described in PNMI[9].

6.  Principal Recommendations

6.1.  RFC 1294

6.1.1.  Specific Encoding

RFC 1294 specifies the transmission of datagrams in a format
according to Q.922.  As this is an HDLC framing, it is  com-
pletely suitable for use on an ISDN B channel.

The RFC does not describe how the Q.922 header is generated;
it was assumed that a genuine frame relay would  provide  it
as a normal consequence of its operation.  All other details
of the encapsulation were completely specified by this  RFC.

In  fact,  it is possible to employ ISDN to gain access to a
Frame Relay, and when doing so packets received from it will
contain  a  valid  DLCI.   Obviously, a system communicating
with a frame relay must set the DLCI's appropriately.

When transmitting datagrams across an ISDN  B-channel  using
this format between systems which are not Frame Relays, such
systems MUST provide a valid DLCI header.  As such, the low-
est  order  bit  of the first byte transmitted MUST be zero.
The DLCI may be configured by prior agreement to any accept-
able  value.   A default DLCI value of 16 is consistent with
current  ANSI  recommendations  (T1.617),  however  at  some
future  time  when frame relay service is offered over the D
channel, the default DLCI value should be 512 (T1.618).

6.1.2.  Advantages of Frame Relay Encapsulation

Proponents for this method have claimed that RFC 1294 encap-
sulation is very simple to implement; in fact it is possible
to prepend  a  fixed  header  to  all  datagrams  sent,  and


Sklower                                     [Page 3]



Draft                Multiprotocol ISDN            Feb. 1993


completely  ignore  the  first  few  bytes  of  any datagram
received.

When systems have been compatibly preconfigured, no  further
state  must be maintained on a per B-channel basis.  This is
clearly of concern for circumstances like  multiple  primary
rate  interfaces  coming  into  a single router, thus poten-
tially supporting hundreds of B-Channels.

Furthermore, it is possible to start  transmitting  data  as
soon  as  the circuit has been established, thereby reducing
latency.  PPP and X.25, by contrast require an  exchange  of
packets to declare the link up.

6.2.  PPP

The  proponents for PPP argue that it is widely implemented,
and constructed in such a  way  to  force  interoperability.
The  details  of  the  protocol  are completely specified by
RFC's 1331 and 1332, and are also applicable to  any  situa-
tion  where  synchronous  transmission  of data is possible.
They argue that any commercial router one procures is likely
already  to  have  code  supporting  PPP, and it is flexible
enough to adapt to all the situations cited as  applications
in this memo.

6.3.  RFC 1356/B-Channel X.25

Systems  supporting  exchanging information according to OSI
conventions are required to support X.25 over the B-channel,
and RFC 1356 provides means for conveying Internet Protocols
in this situation.

7.  In-Band Link Protocol Negotiation

The algorithm is that the caller starts transmitting data or
negotiation  according  to  his preferred encapsulation, and
the callee just figures out what is desired by inspection of
the  first  correctly  framed  HDLC  packet.   If either the
caller or callee insists on doing PPP or  X.25  it  will  be
impossible to shut them up.

7.1.  Caller's Algorithm

A  system  wishing  to  exchange  information using RFC-1294
encapsulation MUST transmit some packet with  a  valid  two-
byte  DLCI.   The  calling system MAY transmit protocol data
immediately, given suitable preconfiguration.   The  calling
system  MAY also initiate parameter negotiation according to
PNMI, using the RFC-1294 encapsulation.

A system wishing to  exchange  information  using  PPP  will
issue  an  LCP packet in native PPP format, according to the


Sklower                                     [Page 4]



Draft                Multiprotocol ISDN            Feb. 1993


requirements of RFC 1331; i.e. the first byte will be  0xff,
and the second byte will be 0x3, etc.

A  system  wishing  to  use  X.25  will issue a SABM with an
address of station A,  according  to  the  OSI  implementors
agreement [10].

7.2.  Callee's Algorithm

The  called  system  will  wait until it has received a cor-
rectly framed and checksummed HDLC packet  and  inspect  the
very  first  byte.  PPP requires that the station address be
all ones (0xff).  Conventional X.25 HDLC requires a  station
address of either 1 or 3.  The 2,3 or 4 byte DLCI Q.922 for-
mats all require that the low order bit of the first byte to
be  zero.  Thus, it is possible for a called system support-
ing all  three  methods  to  unambiguously  determine  which
encapsulation is desired and respond in the appropriate man-
ner.

8.  Out of Band Signaling

{Warning - Meta paragraph.  At the last IETF meeting, it was
agreed  that  somebody  would  approach ANSI for obtaining a
code point for the LLC-IE byte 7 "user information  layer  3
protocol"  that would indicate PPP.  I probably have botched
this section but I'm going to include it to make  it  easier
for whoever edits this next}.

8.1.  Caller's Requirements

In  cases where the LLC information element is available and
can be transmitted to be relied on end to end, and the  sys-
tem  wishes to communicate using the RFC-1294 encapsulation,
a system MUST encode the LLC-IE in the following way in  his
setup message:



















Sklower                                     [Page 5]



Draft                Multiprotocol ISDN            Feb. 1993


8        7     6       5    4    3    2    1
- -----------------------------------------------------------
0        1     1       1    1    1    0    0
0               Low Layer Compatibility                     Octet 1
- -----------------------------------------------------------
               .
               .
               .
- -----------------------------------------------------------
1        1     0       0    1    1    1    1                Octet 6
ext   layer 2 ident    Core Aspects of Q.922 (Frame Relay)

- -or-

1        1     0       0    1    1    1    0                Octet 6
ext   layer 2 ident    Full Q.922 (LAPF)
- -----------------------------------------------------------
1        1     1       0    1    0    1    1                Octet 7
ext   layer 3 ident    ISO/IEC TR 9577 (Protocol Identifi-
         cation in the Network Layer)
- -----------------------------------------------------------

In  cases  where  the  system wishes to exchange information
using RFC-1356/X.25 PLP/LAPB a system MUST encode the LLC-IE
in the following way in his setup message:


8        7     6       5    4    3    2    1
- -----------------------------------------------------------
0        1     1       1    1    1    0    0
0               Low Layer Compatibility                     Octet 1
- -----------------------------------------------------------
               .
               .
               .
- -----------------------------------------------------------
1        1     1       0    0    1    1    0                Octet 6
ext   layer 2 ident    CCITT Recommendation X.25 link level
- -----------------------------------------------------------
1        1     1       0    0    1    1    0                Octet 7
ext   layer 3 ident    CCITT Recommendation X.25 packet level
- -----------------------------------------------------------

8.2.  Callee's Algorithm

If the LLC-IE exactly matches that generated by the caller's
algorithm, the system SHOULD proceed according to the encap-
sulations  spelled  out  here.   The  callee MAY inspect the
first correctly framed HDLC packet to see  that  it  matches
the encapsulation scheme described.

If  the LLC-IE contains other values, the system SHOULD pro-
ceed according to the ``wait-and-see''  algorithm  described


Sklower                                     [Page 6]



Draft                Multiprotocol ISDN            Feb. 1993


above.   However,  system  MAY refuse the connection, or the
system MAY make the following inferences: If the User infor-
mation  layer  3  protocol is 0 1 0 0 0 (ISO 8348 Connection
oriented  network  service),  the  system  MAY  assume  that
RFC-1356/X.25  operation is requested.  If the User informa-
tion layer 3 protocol is 0 1 0 0 1  the  system  MAY  assume
that  only  ISO  8473 packets will be routed, (just as if an
X.25 call had been placed with a CUD of 81).

A system MAY also assume  that  octet  7  with  a  value  of
0 1 1 1 0  indicates  a  desire  to encapsulate according to
RFC-1294.

9.  Addressing Stated Requirements of Earlier Work

9.1.  Leifer et al

A goal of this proposal was to be able to use  bandwidth  on
demand,  and  obtain the advantage of using multiple B chan-
nels for transmitting traffic between two hosts.

There are a number of possible ways of doing this which will
be discussed at length in a separate draft.  For purposes of
illustration, we will summarize the methods discussed at the
November,  1992  IETF:  Almost  all the methods require some
means of identifying which channels are  to  be  aggregated,
which  could  be  done  by the methods discussed in PNMI, or
potentially by use of the calling party information element.

 (1)   Use  the  bank-teller's  algorithm: assign a complete
       packet to whatever channel is next free.

 (2)   Employ ISO 7776[11] multilink  procedure.   (This  is
       being pursued by the PPP working group).

 (3)   Adapt  the  fragmentation  and  reassembly scheme for
       RFC-1294 for bridged packets, regarding the  fragment
       identifier  as  applying  to all packets from a given
       peer rather than from a given PVC.

 (4)   Rely on hardware and packet switching facilities that
       combine  multiple B-channels into a single (HDLC) bit
       stream, such as the BONDING proposal currently  being
       discussed by ANSI T1.

9.2.  Murakami et al

A  major  concern  of  this paper was the use of out-of-band
signaling to negotiate compatible configuration  parameters.
It is the contention of this author that any parameter need-
ing to be negotiated in this scheme should  be  able  to  be
done so by PNMI, and if it can't then PPP should be extended
to negotiate that parameter.


Sklower                                     [Page 7]



Draft                Multiprotocol ISDN            Feb. 1993


10.  References

[1]  Leifer, D., Sheldon, S., and Gorsline B., "A Subnetwork
     Control  Protocol  for  ISDN  Circuit-Switching" IPLPDN
     Working Group, Internet Draft (Expired), March 1991.

[2]  Muramaki, K., and Sugawara, T., "A Negotiation Protocol
     for  Mutliple  Link-Protocol  over ISDN Circuit Switch-
     ing", IPLPDN Working  Group,  Committee  Document,  May
     1992.

[3]  Romkey,  J.L.,  "A  Nonstandard  for Transmission of IP
     Datagrams over Serial Lines:  SLIP."   Network  Working
     Group, RFC-1055, June 1988.

[4]  Simpson, W., "The Point-to-Point Protocol (PPP) for the
     Transmission of Multi-protocol Datagrams over Point-to-
     Point  Links",  Network  Working  Group,  RFC-1331, May
     1992.

[5]  McGregor, G., "The PPP Internet Protocol Control Proto-
     col  (IPCP)" Network Working Group, RFC-1332, May 1992.

[6]  CCITT, "Recommendation V.120: Data Communications  over
     the Telephone Network" Blue Book, ITU 1988

[7]  Malis,  A.,  Robinson,  D.,  Ullman  R., "Multiprotocol
     Interconnect on X.25 and ISDN in the Packet Mode", Net-
     work Working Group, RFC-1356, August 1992.

[8]  Bradley,  T.,  Brown, C., and Malis, A., "Multiprotocol
     Interconnect over Frame Relay", Network Working  Group,
     RFC-1294, January 1992.

[9]  Sklower,  K.  and Frost, C.  "Parameter Negotiation for
     the Multiprotocol Interconnect" IPLPDN  Working  Group,
     Committee Document, November 1992.

[10] Boland,  F.,  editor, "Stable Implementation Agreements
     for Open Systems Interconnection Protocols:  Version  2
     Edition  1",  NIST  Workshop  for  Implementors of OSI,
     NIST, February 1989.

[11] Internation Organisation for Standardization,  "HDLC  -
     Description  of  the X.25 LAPB-Compatible DTE Data Link
     Procedures", Internation Standard 7776, 1988

11.  Author's Address

Keith Sklower
Computer Science Department
570 Evans Hall
University of California


Sklower                                     [Page 8]



Draft                Multiprotocol ISDN            Feb. 1993


Berkeley, CA  94720

Phone:  [phone]
Email:  [e-mail]

12.  Expiration Date of this Draft

August 16, 1993















































Sklower                                     [Page 9]


------- End of Forwarded Message